Date: Sat, 11 Dec 93 04:30:26 PST 

From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu> 
Errors-To: Ham-Digital-Errors@UCSD.Edu 

Reply-To: Ham-Digital@UCSD.Edu 

Precedence: Bulk 

Subject: Ham-Digital Digest V93 #143 

To: Ham-Digital 


Ham-Digital Digest Sat, 11 Dec 93 Volume 93 : Issue 143 


Today's Topics: 
1933 vs. 1935 HDLC 
9k6 baud packet - is there any point? 
COMPLETE Documented NOS Wanted 

Digital Cellular 

HP48 Communications (2 msgs) 

Need advice on using tube-final rigs for RTTY/AFSK 

NETMGR a tool for R.O.S.E. 

Scrambler lockup 
W9GR DSP article of Sept 1992 QST 

X13 at 38.4 kbps 


Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu> 
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu> 
Problems you can't solve otherwise to brian@ucsd.edu. 


Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital". 


We trust that readers are intelligent enough to realize that all text 
herein consists of personal comments and does not represent the official 
policies or positions of any party. Your mileage may vary. So there. 


Date: Thu, 9 Dec 1993 05:35:17 GMT 
From: news.Hawaii.Edu!tony@ames.arpa 
Subject: 1933 vs. 1935 HDLC 

To: ham-digital@ucsd.edu 


What is the difference between a WD 1933 and a WD 1935? I notice that the 
manual/schematic for some TNC-1 clones show a 1933 but when you pop the thing 
open there's a 1935 in there. 


Antonio Querubin 
tony@mpg.phys.hawaii.edu / ah6bw@uhm.ampr.org / querubin@uhunix.bitnet 


Date: 10 Dec 1993 11:10:25 -0600 

From: mvb.saic.com!unogate!news.service.uci.edu!usc!howland.reston.ans.net!gatech! 
concert! corpgate! crchh327.bnr.ca!debaker@network.ucsd.edu 

Subject: 9k6 baud packet - is there any point? 

To: ham-digital@ucsd.edu 


In article <755446538snx@llondel.demon.co.uk>, dave@llondel.demon.co.uk (David 
Hough) writes: 

|> In article <FROUD.93Dec8202731@sunlab41.sx.ac.uk> froud@sunlab41.sx.ac.uk (How 
much wood could a woodchuck chuck if a woodchuck could chuck wood?) writes: 

|> >Just a minor point I wouldn't mind cleared up if anyone has a few seconds... 
|> > 

|> >I read that rigs had to be modified to allow upwards of 2k4 baud transmission, 
|> >but is this pointless if the person you are trying to commmunicate with 

|> >hasn't a repicrocal modification at the either end to allow reception of 

|> >higher baud transmissions? 

|> > 

|> Unlike land-line modems, there is no speed negotiation on packet (unless you 
|> are using strange kit) so you have to set up your rig/TNC to work at a 

|> particular speed. Once you have tried 9600baud you will think that 1200 is 

|> xveryx slow. It isn't hard to modify rigs either.... 


PAV AY AV AVAYAVAVAYATAVATAVAVATATATATATATATATATATATATATATATATATATATATATAVATATAVAS 


OK, now I am ready to get some info on modifying rigs for 9600! I havea 
kenwood TM-742A that I would like to use...does anyone know where I can find 
information explaining how to do this? 


Also, how do I go about finding a 'full sevice PBBS' (if that is what I am 
looking for) in order to send long distance packet mail, i.e. to an address 
of a person in another city or state (or country)?? 


|> 

|> Dave 

eae 

|> 

| > KAKA I KAA IA IK KAI III III IKI III III III III KIKI III III IKK IIIA IIIA IAAI 
|> * G4WRW @ GB7WRW.#41.GBR.EU AX25 * Start at the beginning. Go on * 
|> * dave@llondel.demon.co.uk Internet x until the end. Then stop. * 
|> * g4wrw@g4wrw. ampr.org Amprnet x (the king to the white rabbit) x 


|> KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKKKKK 


Thanks, 

73, 

| David E. Baker Sia So Opinions expressed are | 
| Callsign: AB5PI mine, and they do not | 


| Internet: debaker@bnr.ca necessarily reflect 
| IP Addr: 47.122.65.7 the opinions of BNR or | 
| Unix ID: crchh7b0 or Northern Telecom. | 


Date: Wed, 8 Dec 1993 18:32:12 GMT 

From: nih-csl!helix.nih.gov!mack@uunet.uu.net 
Subject: COMPLETE Documented NOS Wanted 

To: ham-digital@ucsd.edu 


In article <9312012304.tn22729@aol.com> <mattharvey@aol.com> writes: 
>I would like to know how I could attain a copy of the latest version of KA9Q 
>unmodified NOS. I would appreciate it if I could find a package with complete 
>documentation that includes the file BM.EXE. Please send responses to 
>MattHarvey@aol.com OR KD4AZH@KB4GBS.4#TPA.FL.US.NOAM. 
> 

>Thank you. 

Do you know about the book from tthe ARRL (forget what it's called - 
comething like NOSGUIDE). Unfortunately it's pitched at a very 

low level. 

Joe NA3T 

mack@ncifcrft.gov 


Date: Wed, 08 Dec 93 12:49:04 MST 

From: pacbell.com!sgiblab!swrinde!cs.utexas.edu!asuvax!ennews!stat!aznet! 
dan@network.ucsd.edu 

Subject: Digital Cellular 

To: ham-digital@ucsd.edu 


We are currently running Digital in our system, but it is still undergoing 
testing and is not accessible by the public just yet. We are testing the 
format of CDMA. 


dan@aznet.stat.com 

Daniel J. Meredith 

Fax - (602) 956-2566 
Voice - (602) 809-0555 


Date: 10 Dec 1993 08:39:06 -0600 

From: mvb.saic.com!unogate!news.service.uci.edu!usc!cs.utexas.edu!swrinde! gatech! 
news-feed-1.peachnet.edu! concert! corpgate!crchh327.bnr.ca! kharker@network.ucsd.edu 
Subject: HP48 Communications 

To: ham-digital@ucsd.edu 


In article <jann0004-091293230819@dialup-1-75.gw.umn.edu>, 
jann0004@maroon.tc.umn.edu (Scott Jann) writes: 

|> I am looking for a cheap way to communicate between two HP-48 calculators 
|> (longer than the build in IR can do), maybe 50-100 feet. I have heard of 
|> people modifying walkie-talkies to use with the hp48. I don't want to use 
|> TNC equipment....too expensive for me. 

|> How would I go about modifying a walkie-talkie to do digital 

|> communications? I don't care about error checking or anything, just a way 
|> to send simple ascii messages. 

|> Can anyone help me with doing this? 

|> 

|> Thanks 


As another idea, I have seen infrared "repeaters" little red pyramid-shaped 
things that relay the signals of tv remotes and whatnot. Perhaps a strategically 
placed one (if you're going to be using the calculators basically in the same area 
all the time) would do the trick. Don't know where you'd go to find one of these 
things. Probably saw it in a Damark catalog or someplace like that. 


Kenneth E. Harker BNR "Any opinions expressed 
kharker@bnr.ca Richardson, Texas, USA are solely mine and do 
N1PVB (214) 684-5115 not represent BNR" 


Date: Fri, 10 Dec 1993 05:12:47 GMT 

From: pacbell.com!sgiblab!swrinde!cs.utexas.edu! howland.reston.ans.net!gatech! 
news-feed-1.peachnet.edu!umn.edu!dialup-1-75.sw.umn.edu!user@network.ucsd.edu 
Subject: HP48 Communications 

To: ham-digital@ucsd.edu 


I am looking for a cheap way to communicate between two HP-48 calculators 
(longer than the build in IR can do), maybe 50-100 feet. I have heard of 
people modifying walkie-talkies to use with the hp48. I don't want to use 
TNC equipment....too expensive for me. 

How would I go about modifying a walkie-talkie to do digital 
communications? I don't care about error checking or anything, just a way 
to send simple ascii messages. 

Can anyone help me with doing this? 


Thanks 


Date: Thu, 9 Dec 1993 16:50:30 GMT 

From: pravda.sdsc.edu!usc!howland.reston.ans.net!europa.eng.gtefsd.com!emory! 
rsiatl!ke4zv! gary@network.ucsd.edu 

Subject: Need advice on using tube-final rigs for RTTY/AFSK 

To: ham-digital@ucsd.edu 


In article <CHqHJ9.Awz@srgenprp.sr.hp.com> alanb@sr.hp.com (Alan Bloom) writes: 
>Patric M Stickler (stickler@klaava.Helsinki.FI) wrote: 

>: How can one 

>: estimate the max. drive the finals can take at 100% duty cycle? 

> 

>If the rig has an AM mode, use the AM carrier power rating. 


Good. 


>Even better, mount a 3 or 5-inch muffin fan on the side of the cabinet 
>blowing directly on the final amplifier tubes. With that, you should 
>be able to run full CW power on digital modes. The main limitation then 
>will be the power transformer -- As long as you keep the transmit time 
>below 50% (at least 50% listening time), you should be OK. 

Not so good. The limitation isn't usually raw envelope temperature, it's 
the temperature of the plate structure and the seals at the connections. 
With sweep tubes, you can't cool them effectively enough with a muffin fan 
to get even 50% power, much less 100% power when key down time exceeds a 
few seconds. The plate structures aren't up to it, and you need to get 
airflow across the base seals, and they're masked by the tube socket. 

Real transmitting tubes are better because their plate structures are 
heavier, but you still have seal problems unless you have air sockets. 
Best, of course, are external anode tubes mounted in proper air sockets 
with proper chimneys. 


Low duty cycles are good, but you still have to watch absolute key 
down times. If the key down time exceeds the thermal inertia of the 
tube, you've got to treat it like it's 100% duty cycle use. 


Gary 
Gary Coffman KE4ZV | I kill you, | gatech!wa4mei! ke4zv! gary 
Destructive Testing Systems | You kill me, | uunet!rsiatl! ke4zv! gary 
534 Shannon Way | We're the Manson Family | emory!kd4nc!ke4zv! gary 

| 


Lawrenceville, GA 30244 | -sorry Barney 


Date: 7 Dec 1993 22:45:42 -0500 

From: kb2ear.ampr.org!not-for-mail@princeton.edu 
Subject: NETMGR a tool for R.O.S.E. 

To: ham-digital@ucsd.edu 


Bill Slack NX2P asked me to post this. 


NETMGR is a Windows based ROSE network managment took. It 
allows the ROSE network manager or switchOP to graphically 
draw the network (or part of the network) and automatically 
generate the configuration files. In most cases no manual 
editing of the configuration files will be neccessary. 


If you would like a copy and don't have FTP please send me email and I 
send a copy via email. Or I'll post somewhere on USENET. 


What FTP sites should I post this on? 


If you would like more info about ROSE send email to 
askrat@kb2ear.ampr.org and/or get on the ROSE mailing list. To get on 
the mailing list send email to listserv@kb2ear.ampr.org with this line 
as the body: 


ADD rose 

or 

ADD <Your_Address> rose 

To post to the list send email to rose@kb2ear.ampr.org. 


73, 

Scott R. Weis KB2EAR 

Internet: kb2ear@kb2ear.ampr.org 

Snail Mail: 10 Palmer Rd., Kendall Park, NJ, 08824-1228 
Phone: +1 908 297 0469 


Date: 11 Dec 93 05:55:25 GMT 
From: news-mail-gateway@ucsd.edu 
Subject: Scrambler lockup 

To: ham-digital@ucsd.edu 


Here in Utah, we have designed and run some test on a T1 radio modem. 


The modem appears to work very well but there is an area of slight concern: 
This modem uses a 17 bit maximal-length scrambler (taps on bits 5 and 17). 


This scrambler uses the same circuit topography as the scrambler in the GRAPES 
modem and uses 2 XOR gates (74HC86) 2 shift registers (2 74HC164's) and 
a flip-flop (1/2 of a 74HC74). 


The problem seems to be that there some unsusal circumstances (cause unknown) 
in which the scrambler seems to get "stuck". Since this sequence generator 
is obstensively an open loop system (as opposed to a PN generator used for 
Spread Spectrum) I don't see how this should be able to occur, but occur 

it can. 


Has anyone else had experience with this sort of scrambler and had to deal 
with this problem? 


Several things come to mind: On could detect the lack of appropriate 
transitions and reset the system to get it working once again. One could 
also have the system software detect a stoppage of the data and cause a reset 
to be issued. 


Interestingly enough, the descrambler, which is nearly identical to the 
scrambler, does NOT seem to exhibit this sort of behavior. 


We will soon be using these modems in a full-duplex T1 microwave link and 
will report on their performance. 


<Clint> 


ka7oei@uugate.wa7slg.ampr.org 
clint@uugate.aim.utah.edu 


Date: Wed, 8 Dec 1993 19:53:03 GMT 

From: mel.dit.csiro.au!its.csiro.au!dmssyd.syd.dms.CSIRO.AU! metro! 
basser.cs.su.oz.au!harbinger.cc.monash.edu.au!yeshua.marcam.com! 
zip.eecs.umich.edu!umn.edu! news-feed-2.@@munnari.oz.au 

Subject: W9GR DSP article of Sept 1992 QST 

To: ham-digital@ucsd.edu 


In article <1993Dec7.184551.24853@kpc.com>, nat@kpc.com (Natarajan Gurumoorthy) 
writes: 

|> Hi, 

|> I just stumbled across W9GR's article and am itching to build it. 

|> I have several questions: 


|> 2. The article mentions that the TI assembly files for the prom code 
|> are available on compuserve. Are they also available at some internet ftp site. 
|> Any pointers would be helpful. 

|> 3. The article also mentions that the prom programming files are 

|> also available. Again pointers would be helpful. 

|> 

I found these files via anonymous ftp at nic.funet.fi. Get into 
the machine and cd to directory /pub/ham/dsp/w9gr. The name of the file is 
w9gr.zip. The file contains the prom programming files as well as the 
assembly sources for the lms and 3 CW filters. I located the files through 
the archie server at UNL Nebraska. 

Enjoy 

Nat. 


Natarajan Gurumoorthy AB6SJ Kubota Pacific Computer, Inc. 
nat@kpc.com 2630 Walsh Avenue 
Phone 408 987 3341 Santa Clara, California 95051. 


Date: 10 Dec 93 20:55:42 GMT 

From: ogicse!cs.uoregon.edu!sgiblab!sdd.hp.com!col.hp.com!srgenprp! 
glenne@network.ucsd.edu 

Subject: X1J at 38.4 kbps 

To: ham-digital@ucsd.edu 


Since posting the basenote, I've had some very helpful and useful 
exchanges with Dave Roberts, the author of X1J. In addition, the remote 
site I mentioned has been visited and the TNC running X1J was replaced 
with another which has a DCD state machine. Also, several days after 
vanishing from the band, the remote X1J started functioning, poorly but 
still working, again. 


In considering the differences between the remote X1J and one in the 
hamshack (allright, it's really the garage) I came to the idea that 
maybe what was happening wasn't due to the fundamental inability of X1J 
to run fast enough. Dave's comments substantiated this. 


Due to the difference of DCD signals, the remote node had been running 
full duplex. This required limiting MAXFRAME to one but that was 
tolerable. I had set the node to FDX in order to ignore the RF derived 
DCD coming from the radio which in this case can tend to have a lot of 
edges due to Part 15 and other devices sharing 902-928 MHz. However, 
the radios are also designed such that RxD is qualified by DCD, even if 
the TNC ignores DCD, RxD doesn't. With a loosely set squelch and/or lots 
of fast FH spread spectrum signals there can be a xlotx of edges. With 


a loose squelch the RxD line is a gated version of what the 
discriminator sees (which is very noisy with a lot of fast edges in the 
500 KHz bandwidth) . 


I now suspect that the radio squelch was set loose and the radio could 
probably hear itself weakly (noisey) during transmit. The problem I saw 
was likely the result of a tremendous number of interrupts from the 
receive side of the TNC SIO (probably mostly receive aborts or errors of 
some kind). I expect that the receive interrupts have higher priority 
than transmit interrupts and consequently the transmit side was able to 
run out of data to send and reported underruns. 


Since replacing the TNC and disabling FDX the excessive number of 
underruns disappeared and performance has returned to the same level as 
that of the local X1J boxes. The X1J code does require considerable 
overhead so performance isn't stellar, but it xdoesx seem to run now at 
38.4 kbps. Ping RTT is about 300 milliseconds. This is way longer than 
the raw channel rate alone requires but it xdoes* still allow higher 
speed data to go through the node and offers remote diagnostics. 


Following Dave's advice, I've disabled mheard and nodes broadcasts and 
will use minqual to effectively disable NET/ROM operation. 


So, for anyone else wanting faster operation and KISS in a standalone 
box for lowcost, X1J still seems viable to 38.4 kbps. I still hope to 
get a version of K3MC KISS code modified to include digipeating since I 
think this might be able to run my radios much faster, perhaps in the 
100-200 kbps territory. If this happens before the fullspeed controllers 
are working properly I'll probably try to get that code installed in the 
TNCs. 


All this is certainly trying to squeeze an underpowered platform, the 
TNC2, but it is still a lot less expensive than the few alternatives, 
Gracilis, the German TNC3 and perhaps the Data Engine and presently it 
is more available than MIO. I think that it points to a general issue 
though; as we seek higher speeds we will continue to need to handle as 
much of the "pre-filtering" in hardware as possible. Building radio 
hardware which has data which is as "qualified" as possible, along with 
doing FEC in hardware rather than software may be requirements as we 
push for performance. Picking radio methods (like SS or equalization) 
combined with fast hardware FEC to provide "host ready" data may be a 
necessary. 


The TNC was originally designed as an interface between a "dumb radio" 
and a dumb terminal. As we've increasingly run higher levels of 
complexity, TCP/IP and other networking protocols, we've drifted toward 
"doing the hard part in the increasingly powerful local host. KISS 
protocol is an example of this. However, as we turn the speed up, I 


think many functions like "data cleaning" and FEC if not some of the 
higher ones like switching/routing may have to be done closer to the 
physical medium again. 


Glenn Elmore négn 


ax.25 n6gn@wx3k.#nocal.ca.usa.na 
amateur IP: glenn@SantaRosa.ampr.org 
Internet: glenne@sr.hp.com 


End of Ham-Digital Digest V93 #143 
KKKKKKKKKKKKKKKKKKKKKKKEKERR KKK 
KKKKKKKKKKKKKKKKKKKKKEKKKERKA KKK 


